!pr1
65C02s in Old Apples...............................Jim Sather

I read Andrew Jackson's 12/84 AAL comments on 65C02 operation in an Apple II with interest since I had looked into the same subject while doing research for "Understanding the Apple IIe".  I share Mr. Jackson's conclusion that the problem is short read data setup time from motherboard RAM, but I disagree with his analysis and conclusion that a 65C02 only gets a setup of 25 nsec in an Apple II.

The motherboard RAM read data setup time in an Apple II is

        70 nsec (one 14M period)
  minus LS174 pin 9 to data out propagation delay (B5/B8 latch)
  minus LS257 data propagation delay (B6/B7 mux)
  minus 8304 or 8T28 data propagation delay (H10/H11 driver)
   plus MPU PHASE 0 to PHASE 2 propagation delay
   plus 74LS08 propagation delay (B11 PHASE 0 gate).

Longer PHASE 0 - PHASE 2 delays result in longer read data setup time, not shorter.  With the 6502s and 65C02s I have experimented with, PHASE 0 to PHASE 2 delay has always been in the 20-40 nsec region.  Whatever the variation, I have found no NCR or GTE 65C02 that will work in my Apple II.

Taking all delays into account, the motherboard read data setup time for a 6502 or 65C02 is about 65 nsec.  This is not good enough for 1 MHz 6502/65C02 specifications but it is good enough for 2 MHz 6502/65C02 specifications.  In other words, the Apple II does not meet the read data setup spec of the 1 MHz 6502 that it was manufactured with.  Based on this fact, the 100 nsec read data setup spec of 1 MHz 6502s is unrealistically conservative.

But why won't a 2 MHz 65C02 run in the Apple II if it requires only 50 nsec setup time and it gets 65 nsec?  The answer, in my opinion, is that NCR and GTE 2 MHz 65C02s do not operate to spec.  With certain instruction sequences, they require more than 50 (and, in fact, more than 65) nsec read data setup time.  The instruction sequences that bomb are VERY limited, so the 65C02 only gets into trouble when a certain few code sequences are executed.  The 65C02 symptom in the Apple II is, therefore, that most things work, but some don't.

Efforts to improve 65C02 operation in the Apple II can be concentrated on decreasing data delays (by replacing the LS174s and LS257s with equivalent devices from a faster logic family) or increasing MPU data clock delays (by adding TTL devices in series with the MPU PHASE 0 input).  Possible reduction in data delays is limited, so increased MPU PHASE 0 delay is tempting.  Be forewarned, though, that 6502 PHASE 2 is already very late for peripheral slot and serial input mux data transfer, and that such data transfer already depends on the long bleed off time of data from the floating data bus.  It is certainly feasible that some Apples with heavy data bus loads will begin to show bugs if any MPU PHASE 0 delay is introduced.  But in all probability, you can increase the MPU PHASE 0 delay in a given Apple until MPU PHASE 2 falls concurrently with RAM SELECT' after access to an address above $C00F in the Apple II.  This point is 60 nsec after peripheral slot PHASE 0 falls in my Apple II.

AAL readers may be interested in the following excerpt from "Understanding the Apple IIe".  It details some features of the 65C02 which are not clear from the data sheet and describes instruction sequences that I have found that make NCR and GTE 65C02s bomb in an Apple II.  Note particularly that I have a Rockwell 1 MHz 65C02 that operates without a hitch in my Apple II.  This may be a lucky coincidence, or Rockwell 65C02s may not have the read data setup problems of the NCR and GTE chips.


[ Following is an excerpt from "Understanding the Apple //e", copyright (c) 1985 by Quality Software, published here by permission of Quality Software. ]

THE 65C02 MICROPROCESSOR

A recent development in the 6502 world has been the introduction of the 65C02 MPU.  This MPU (manufactured by NCR, Rockwell, and alternate sources) is fabricated using CMOS technology, instead of the NMOS used in the 6502.  The general advantage of CMOS over NMOS is lower power consumption, but the 65C02 also has some new instructions which make it operationally more powerful than its NMOS brother.  A 65C02 can execute any 6502 program that doesn't depend on fine instruction execution timing, but a 6502 cannot execute 65C02 programs that utilize the new 65C02 instructions.

Apple uses the 65C02 MPU in the Apple //c microcomputer, and they intend to convert the Apple //e over to the 65C02.  The plan is to retrofit older Apple //e's with the 65C02 as part of the firmware upgrade package described in Chapter 6.  This will maximize compatiblity betweeen the Apple //e and the Apple //c, and make it possible to write shorter and faster Apple //e assembly language programs.  Because the Apple //e may become a 65C02 based computer in the future, some data on the 65C02 is given here and in other parts of "Understanding the Apple //e".

The 65C02 improvements consist of the addition of new instructions and addressing modes, and the removal of some old 6502 bugs.  For the most part, differences between the 6502 and 65C02 are well documented in the partial NCR 65C02 data sheet in Appendix C at the back of this book.  Descriptions here will therefore be limited to a few points whose ramifications are not made entriely clear by the data sheet.  Please note also that details of 65C02 instruction execution are given in Tables 4.3 and 4.4 in an application note later in this chapter.

First, the NCR and Rockwell 65C02s are not identical.  The Rockwell chip executes some instructions that are not part of the NCR 65C02  repertoire.  These are the zero page instructions RMBn (Reset Memory Bit n) and SMBn (Set Memory Bit n), and the zero page relative branch instructions BBRn (Branch on Bit n Reset) and BBSn (Branch on Bit n Set).  The opcodes of these Rockwell instructions ($X7 and $XF) represent NOPs in the NCR chip.  Apple appears to be using NCR compatible 65C02s in its computers, but the Rockwell chip works fine in the Apple //e.  Please refer to Tables 4.3 and 4.4 for details of the additional Rockwell instructions.

The READY line of a 6502 will not halt the MPU during a write cycle, but the 65C02 READY line will.  This raises the question, "what happens to the Apple IIe data bus if READY is pulled low during a write cycle and is held low for a number of following write cycles?"  If the 65C02 attempts to control the data bus constantly for a series of wait state write cycles, it will compete with motherboard RAM for control of the data bus near the end of PHASE 1.  Investigation shows that this is not a problem.  During a long series of wait state write cycles, the 65C02 control the data bus only during that portion of the machine cycle in which it controls the data bus during a normal write cycle.  Therefore, its data bus connection is at high impedance during the majority of PHASE 1 in all wait state write cycles, and motherboard RAM is free to control the data bus near the end of PHASE 1.

The fact that interrupts do not cause abortion of a BREAK instruction is listed as an operational enhancement of the 65C02 on page 3 of the data sheet.  The data sheet is referring to non-maskable interrupts, not interrupt requests.  In a 6502 or 65C02, IRQ' falling after a BREAK op code fetch does not interfere with BREAK execution.  However, if NMI' falls after a BREAK op code fetch and before the interrupt vector is fetched in a 6502, then the NMI' interrupt vector is fetched, and the NMI' handler is executed.  An RTI at the end of the NMI' handler causes return to the address (plus two) of the BREAK instruction and probable program crashing.  This bug is fixed in the 65C02.  As the data sheet indicates, NMI' falling during BREAK execution results in NMI' execution after BREAK execution is complete.

The NCR data sheet refers to the new increment accumulator and decrement accumulator instrucions as INA and DEA.  I don't know why they do this, because these instructions are clearly just new addressing modes of the INC and DEC instructions.  The new mnemonics should be INC A and DEC A or just INC and DEC as given in the Rockwell data sheet.  The addition of the INC and DEC accumulator addressing modes means these instructions have all the addressing modes of the other 6502 read-modify-write instructions (ASL, LSR, ROL, and ROR).

Another notable feature of the 65C02 data sheet is the 5000- microsecond maximum cycle time in the AC characteristics table on page 3.  I take this to mean that you can stop the clock for a guaranteed minimum of 5000 microseconds with PHASE 0 high, but not with PHASE 0 low.  The Rockwell data sheet is more specific about the difference.  It states:  "The input clock can be held in the high state indefinitely; however, if the input clock is held in the low state longer than 5 microseconds, internal register and data status can be lost".  The significance is that, when the Apple IIe DMA' line is held low, it forces the PHASE 0 input to the MPU to a low state.  I therefore conclude that long term continuous DMA in the Apple IIe cannot be performed with a 65C02 any easier than it can with a 6502.  In either case, long term continuous DMA can only be performed by pulling DMA' low after the MPU has been stopped via READY low, and only after the X4 and X5 Apple IIe motherboard jumpers have been configured so the MPU clock is not stopped when DMA' is pulled low.

A feature of the 65C02 that does not show up in the NCR data sheet is that the new BIT immediate instruction operates differently than BIT in the other addressing modes.  In the other addressing modes, BIT sets the negative, overflow, and zero flags based respectively on operand bit 7, operand bit 6, and the result of Accumulator AND operand.  The 65C02 BIT immediate instruction affects only the zero flag, not the negative and overflow flags.

A final point about 65C02 operation that I'd like to make is mildly speculative.  The 65C02 is pin compatible with the 6502, and was designed as a direct but more powerful substitute for the 6502.  To make it work in the Apple IIe, you simply remove the 6502 and plug in the 65C02.  However, the 65C02 does not work reliably in the older Apple II.  I believe that the reason for this is that the 65C02 (or at least an NCR 65C02) requires read data to be set up longer than a 6502 operating at the same frequency.  RAM read data in the Apple II becomes valid at the MPU (about 60 nsec before PHASE 2 falls) much later than it does in the Apple IIe (about 250 nsec before PHASE 2 falls).  Whereas the 6502 can handle the short RAM read data set up time, the 65C02 seems to have trouble with it.

I have performed limited experiments with 65C02s in an Apple II.  Basically, I found that two NCR 65C02As (2 MHz?) and one NCR compatible GTE G65SC02P-2 (2 MHz) caused intermittent program crashing that got worse as the peripheral card data bus load was increased.  The Rockwell R65C02P1 (1 MHz) that I tried caused no program crashes.  The NCR 65C02 program drashes occurred only with certain data bus sequences.  If an RTS instruction is preceded by a NOP or SBC, and the Apple II video data preceding the RTS opcode fetch is $A0, $A2, or $A9 then the carry flag is set during otherwise normal execution of the RTS instruction.  This unwanted setting of the carry flag occurred as mentioned with all three NCR type chips.  One of the chips also set the carry flag if the video data preceding the RTS was $89, and another one also set the carry flag if the video data preceding RTS was $89 or $E9.  Note that $89, $A0, $A2, $A9, and $E9 are all immediate mode 65C02 instructions.

In these experiments, I did not conclusively prove that the problem with the 65C02 in the Apple II is short set up time of RAM read data.  This is merely a highly educated guess upon which I would be willing to bet a paycheck (if only I had one).  Setting the data up quicker definitely helps, because the bugs mentioned in the previous paragraph do not exist when the program resides in a 16K RAM card whose read data becomes valid just after Q3 falls during PHASE 0.  In any case, I am suspicious of the validity of the NCR claim of 50-nsec minimum read data set up time in its 65C02.
